Hey! I was reviewing this PR chain (#383, #385, #384) and wanted to flag a potential issue with how the generated FirebaseMessagingService interacts with expo-notifications.

The concern: Android only dispatches MESSAGING_EVENT to one service (highest priority wins). In PR #384, when an existing FCM service is detected (e.g. ExpoFirebaseMessagingService from expo-notifications), registration is skipped entirely with a warning to "route Intercom pushes manually" — but Expo users can't write native code, so this effectively means Intercom pushes remain broken for the most common Expo setup.

Priority conflict breakdown:

• Generated IntercomFirebaseMessagingService: priority 10
• ExpoFirebaseMessagingService: priority -1
• Native IntercomFcmMessengerService (from intercom-sdk-fcm): priority -400

If we don't skip and do register at priority 10, Intercom pushes work but super.onMessageReceived() goes to the FirebaseMessagingService base class (no-op), so expo-notifications breaks.

Possible fix: conditionally extend ExpoFirebaseMessagingService instead of FirebaseMessagingService when expo-notifications is present, so super.onMessageReceived() falls through to Expo's handler. Something like:

// When expo-notifications is installed:
class IntercomFirebaseMessagingService : ExpoFirebaseMessagingService() {
    override fun onMessageReceived(remoteMessage: RemoteMessage) {
        if (IntercomModule.isIntercomPush(remoteMessage)) {
            IntercomModule.handleRemotePushMessage(application, remoteMessage)
        } else {
            super.onMessageReceived(remoteMessage) // → Expo handles it
        }
    }
}

The config plugin could detect expo-notifications in the project's dependencies at prebuild time and choose the right superclass.

This would cover the common case where an Expo app uses both expo-notifications and Intercom.